%\documentclass[twoside]{article}
%\usepackage{epsfig,html,amsmath,amssymb,lscape,longtable,pstricks,cite,hyperref}
%\usepackage{graphics}
%\pagestyle{headings}
%\markboth{}{}
%\newcommand{\hytt}[1]{\texttt{\hyphenchar\font=\defaulthyphenchar #1}}

% !Mode:: "TeX:UTF-8"
\documentclass[twoside]{article}
\usepackage{epsfig,html,amsmath,longtable,cite,hyperref}
\usepackage{graphics}
\usepackage{subfigure}
\usepackage{indentfirst}
\usepackage{multicol}
\usepackage{listings}

\usepackage{xeCJK} % seperate the english and chinese

\setCJKmainfont[ItalicFont={AR PL UKai CN}]{AR PL UMing CN} %设置中文默认字体
%\XeTeXlinebreaklocale "zh"  % Auto linebreak for chinese
\XeTeXlinebreakskip = 0pt plus 1pt minus 0.1pt % Auto linebreak for chinese

\setlength{\parindent}{2em}

\begin{document}
	%\linebreak {4}
	%{\kaishu 楷体}
	%{\heiti 黑体}
	%{\fangsong 仿宋}
	\title{电站管道实时监控系统\\软件产品设计规范书}
	\author{
	}
	\maketitle {}
	
	%	\begin{figure}[h]
		%	\centering
		%	\includegraphics[scale=0.6]{fullscreen.png}
		%\epsfig{file=processplant.jpg,width=12cm}
		%\caption{流程工厂\label{cover}}
	%	\end{figure}
	
	\begin{figure}
		\centering
		\includegraphics[scale=0.6]{lining-transferline.png}
		\caption{woo ex.:lining-transferline\label{wooEx}}
	\end{figure}
	\thispagestyle{empty}%目录页不显示页码
	\newpage
	\setcounter{page}{1}%从下面开始编页码
	%\begin{multicols}{2}
	\numberwithin{equation}{subsection}
	
	
	\tableofcontents
	\newpage
	
	
	\section{前言} 
	\subsection{修订历史}
	
	作者	陈工、宋工、石宪方、李国斌	
	
	审核人	陈工、宋工、石宪方、李国斌
	
	完成时间	2019.04.13	
	
	审核时间	2019.04.13
	
	版本修订历史记录：
	
	编号	修订日期	修改作者	修改内容描述和理由	修改的页数
	
	1	2019.04.10		宋工	
	
	2	2019.04.12		李国斌	
	
	3	2019.04.13		李国斌	
	
	4	2020.10.24		李国斌	
	
	5	2021.01.26		陈工	

	6	2021.01.26 		李国斌	
	
	
	本文将功能需求总结书(需求总结)和软件设计规范书(功能设计)合并在一起了。其中需求总结主要由李国斌、宋工、陈工、石宪方完成，李国斌补充了一些内容。
	
	\part{云计算}
	\section{云计算}
	
	云计算（Cloud Computing）是基于互联网的相关服务的增加、使用和交互模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云是网络、互联网的一种比喻说法。过去在图中往往用云来表示电信网，后来也用来表示互联网和底层基础设施的抽象。因此，云计算甚至可以让你体验每秒10万亿次的运算能力，拥有这么强大的计算能力可以模拟核爆炸、预测气候变化和市场发展趋势。用户通过电脑、笔记本、手机等方式接入数据中心，按自己的需求进行运算。
	
	对云计算的定义有多种说法。对于到底什么是云计算，有许多解释。现阶段广为接受的是美国国家标准与技术研究院（NIST）定义：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络，服务器，存储，应用软件，服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。
	
	\subsection{云计算进化史}
	原创|发布：2018-03-11 21:23:16    更新：2018-03-11 21:23:16
	
	阅读 65308赞 1251
	
	链接：https://mp.weixin.qq.com/s/zKOLgB4iH3ddPAoOysMziQ?
	
	个人电脑或许会在不久的将来成为古董，提醒人们曾有过一个奇特的时代：所有人都被迫担任业余的电脑技术人员。
	
	在 19 世纪末期，如果你告诉那些自备发电设备的厂家以后可以不用自己发电，大型集中供电的公用电厂通过无所不在的电网就可以充分满足各种厂家的用电需求，人们一定会以为你在痴人说梦。然后到 20 世纪初，绝大多数公司就改用由公共电网发出的电来驱动自家的机器设备，与此同时，电力还开始走进那些置办不起发电设备或买不起小型中央电厂昂贵电力的百姓家，从而无意中为家用电器的勃兴提供了舞台。
	
	那些没有预计到公用电网出现的公司纷纷陷入了困境，这既包括那些靠生产小型发电设备发了大财的设备生产厂家，也包括一度靠小型中央电厂、区域电网和照明设备垄断市场的电力巨头爱迪生。
	
	大约从2008年开始，在电力领域发生过的故事又开始在 IT 领域上演。由单个公司生产和运营的私人计算机系统，被中央数据处理工厂通过互联网提供的云计算服务所代替，计算机应用正在变成一项公共事业。如此一来，越来越多的公司不再花大钱购买电脑和软件，而选择通过网络来进行信息处理和数据存储，一如当年厂家们放弃购买和维护自由发电设备。那些像 Google 和亚马逊等那样能够提供云计算服务的公司就像当年的公用电力公司一样，必然能占得先机，在一段时间内打败微软和甲骨文等那些沉迷于向私有计算机系统提供软硬件设备的供应商和服务商，直至后者能迎头赶上云计算革命。
	
	不仅仅是公司对于自身信息部门的观念发生了改变。近年来，人们长期以来持有的对电脑的观念也已经发生了巨大的转变，虽然大部分人在家里或上班时仍然依赖个人电脑（毕竟智能手机更多仍被视为休闲娱乐设备），但人们利用个人电脑的方式已与以往非常不同，我们不再依赖电脑硬盘中的数据和软件，而是更多利用公共互联网传来的数据和软件。人们的电脑正在变成这样一种终端，其力量和作用不是主要来自电脑里的内容，而是主要来自电脑连上的互联网——尤其是连入互联网的其他电脑。更极端一点的说法是，整个互联网和所有联网的电脑组成了一个巨大的电脑。
	
	其实早在互联网出现之前，人们就已意识到，从理论上讲，电脑运算的能力和电力一样，可以在大规模公用“电厂”中生产，并通过网络传输到各地。就运营而言，这种中央“发电机”会比分散的私人数据中心更有效率。1961 年，当电脑科学家刚刚开始思考如何让电脑对话时，网络互联领域专家约翰·麦卡锡就预言：“未来电脑运算有可能成为一项公共事业，就像电话系统已成为一项公共事业一样。”
	
	每当网络互联领域出现了新的发展，就会有一批人试图把电脑公用运算搞成一笔大生意。在大型机时代，就有公司在分时运算的基础上将中央电脑租给其他企业使用，使后者能通过电话线与中央电脑直接连接。在 1970 年代，一些像自动数据处理公司那样的企业，已开始在有偿基础上向社会提供某些例行的运算服务，比如工资数据处理。
	
	当蒂姆·伯纳斯-李在 1990 年创立万维网时，用一个巨大的公共在线数据存储器来取代一切私人的线上线下数据存储器似乎已近在咫尺，而一大批应用服务提供商，也冀望通过互联网向企业传输软件。
	
	然而这一切并没有迅速发生，最大的障碍出现在网线上：能够取代你硬盘中软件的复杂软件，要求拥有迅速转移大量数据的能力，这在传统低速的拨号上网时代是做不到的。运行复杂软件会使电话线的运载能力迅速超负荷，或对调制解调器造成损坏，个人电脑会因此停机。
	
	但即便如此，早期的互联网依然提供了云计算的雏形。万维网有着一系列强大的技术作为支撑，尤其是那些用于描述和传送数据的软件。这些技术使所有接入互联网的计算机都变成信息处理机，人们很容易就能与他人分享信息和软件编码，并从很多网站和数据库同时接收信息。人们不仅能在互联网上“阅读”，还能在互联网上“书写”，一如人们阅读自己个人硬盘上的内容并写入内容一样，万维网即将变成万维电脑。
	
	光纤电缆和光纤互联网的出现，解决了数据传输的瓶颈，网络空间的重要性终于压倒了电脑内存的重要性。光纤互联网对电脑应用所起的作用，恰如交流电系统对电所起的作用，它使设备所处的位置对用户不再重要。既然数据可以光速在互联网上传输，就能够为远方的用户提供电脑的全部运算能力。运行人们所用软件的服务器电脑可能位于身边的数据中心，也可能位于国家某处的数据中心。
	
	此外，光纤互联网还扮演了当年使不同发电设备并网发电的旋转变流器的作用，令根本不同的、互不兼容的电脑像一个单一的系统般一起工作。通过为数据传输和“翻译”提供通用媒介，光纤互联网刺激中央电脑运算工厂的形成，这种中央工厂可同时为几万或几百万客户服务。许多小公司已经使用在 Google 公司数据中心上运行的软件，来满足自己大部分的日常运算需求。
	
	不少新兴公司开始抢这块蛋糕：几乎每一个传统的需要安装在电脑上的商业软件，都有与之类似的服务在互联网上提供。其他公司则采取了一种不同的做法，它们不经销软件，反而把硬件本身当做一种服务出售，它们建立了大型数据中心，让客户通过联网直接加以利用，每位客户都可自由选择想要运行的软件以及想要存储的数据。更激进的公用运算服务则试图完全取代个人电脑：人们利用个人电脑所做的一切，从文件存储到运行软件，都可以通过电脑运算网络实现。
	
	除了光纤互联网强大的传输功能外，虚拟化技术能力的增强对公用运算的发展提供了不可或缺的助力。所谓虚拟化是指用软件来模拟硬件，而虚拟化能力的提高，离不开电脑芯片效能爆炸性增长，以前运行一台或两台虚拟电脑就会使主计算机电脑的速度大大减慢，但如今普通的微处理器已变得非常强大，可以同时运行许多台虚拟电脑。
	
	由于计算机系统的所有部件，从微处理器、存储驱动器，到联网设备（如路由器、防火墙和符合均衡器）都是以数字方式运行的，所以它们既可以被软件代替，也可以实现虚拟化。对于曾费力地将各种软硬件组装成商业应用系统的人来说，这一切听起来像是天方夜谭，但它正在迅速地变成现实。网络（即互联网）确实成了人们的电脑，过去装在电脑机箱里的各个单独部件——存储信息的硬盘、处理信息的微型芯片、操控信息的软件——现在已经可以分散在世界各地，通过互联网集成， 并供每一个人分享。
	
	随着云计算服务趋向成熟，每个人都能便捷地使用网上丰富的软件服务，利用无限制的在线存储，通过手机、电视等多种不同装置上网和分享数据，个人电脑或许会在不久的将来成为古董，提醒人们曾有过一个奇特的时代：所有人都被迫担任业余的电脑技术人员。
	
	而从长期来看，公司信息技术部门不可能有幸存的机会，一旦企业运算的大部分任务都移出了自由数据中心并进入“云”中，它就没有可以运算的任务，企业甚至是雇员个人将能直接控制信息的处理，而不必依靠一大批技术专家。他们必须另谋生路，一如当年那些负责运行和维系公司自备发电设施的工程师们。
\part{管道实时监控系统需求}
\section{管道实时监控系统需求\label{pipeScadaSRS}}
西安热工研究院有限公司关于管道应力分析软件（开发）的需求
致：长沙优易软件开发有限公司
我公司关于管道应力分析软件（开发）的需求如下，请贵公司评估！
1.能够打开CAESARⅡ的计算文件（.C2），并可重新提交运算，已和营销部沟通，请再次确认；
2.支吊架工作载荷可以按照设定的频率从已有文件中自动获取，并赋值到对应的支吊架上；
3.节点附加位移可以按照设定的频率从已有文件中自动获取，并赋值到对应的节点上；
4.可按照设定的频率自动提交运算，并自动出具一次应力、二次应力计算结果报表。
请贵方按照上述需求评估其可行性，并提供报价预算
此需求文档请勿外传
西安热工研究院有限公司
联系人：陈工
电话：029-82002790 / 13679100802
邮箱：chenshangjun@tpri.com.cn
\subsection{传感器数据采样与输入输出}
传感器用于测量管道位置或动力学、热力学参数，如位移、速度、加速度、应力、应变、载荷、介质温度、压力等，传感器类型有如下几种：

管道应力应变传感器，可使用MEMS传感器。

力传感器可使用惯性传感器如加速度计。

位移传感器可使用图像传感器CIS等。

可以设置或获取传感器测量的物理量单位，或获取其测量值。

传感器测量值可以使用有线或无线协议传输。本项目是将传感器测量值写入到一个文件，但本系统并不要求必须如此。
\subsection{输入输出单位制}
目前本系统只接受法定单位制，即使用如下单位制：力单位N，位移单位m，速度单位m/s，质量单位kg，时间单位s，温度单位C或K，应力单位Pa。
\subsection{模型建立与显示}
目前本系统提供多种方法用于模型建立与显示，但不同的方法使用不同的模块，用户可以选购不同模块。
\subsubsection{使用AutoPDMS建立和显示模型}
AutoPDMS是优易集团开发的一套三维数据CAD/CAE集成设计和仿真系统C++库，目前已经实现了管道、支吊架、电缆桥架、HVAC、设备、建筑、房屋、结构三维建模和管道应力分析，具有设计库、元件库、等级库、属性库、模板库、持久层、图形接口，可以基于局域网或互联网实现多人协同设计或仿真。

此种系统能够建立最复杂的设备、管道、支吊架等模型，但价格也最贵。
\subsubsection{使用AutoPSA建立和显示模型}
AutoPSA是优易集团开发的一套管道应力分析C++库，用于建立和显示、分析管道有限元梁单元模型，可以分析接触和埋地、补偿器、弹簧、限位、导向等各种约束。三维数据CAD/CAE集成设计和仿真系统C++库，目前已经实现了管道、支吊架、电缆桥架、HVAC、设备、建筑、房屋、结构三维建模和管道应力分析，具有设计库、元件库、等级库、属性库、模板库、持久层、图形接口，可以基于局域网或互联网实现多人协同设计或仿真。

此种系统能够建立最复杂的设备、管道、支吊架等模型，但价格也最贵。

\subsubsection{传感器单片机内部数据转换}	
\part{电站管道实时监控系统预算}
\section{电站管道实时监控系统预算\label{pipeScadaMoney}}
\subsection{模型数据输入与采集}

\subsubsection{管道模型和边界条件数据}
0W
\subsubsection{传感器单片机内部数据转换}

\subsubsection{发送器单片机数据发送}

\subsubsection{无线采集器单片机数据接收}

\subsubsection{传感器数据转换}

\subsubsection{传感器数据传输}

\subsubsection{设置温度与位移对应关系}


以下需求由UESOFT实现。
\subsection{实时数据库和时序数据库}

选型与集成。
\subsection{模型数据接口}

\subsubsection{传感器数据采样}


\subsubsection{传感器数据和UE实时数据库URDB接口}

\subsection{模型数据实时设置}

\subsection{模型数据计算}

\subsection{传感器测量数据与计算结果不一致的原因}

\subsubsection{传感器测量数据误差}

\subsubsection{有限元程序代码BUG误差}

\subsubsection{模型原始数据误差\label{modelrawdataerrror}}

\subsection{使传感器测量数据与计算结果一致}

\subsection{测量与计算对比分析}

\subsection{显示和输出}

\section{UE云平台}
 按公有云
\subsection{云服务器}
\subsubsection{私有云：基于局域网}

\subsubsection{公有云：基于互联网}

\subsubsection{私有云：基于VPN}

\subsection{云客户端后台}

\subsubsection{私有云：基于局域网}

\subsubsection{公有云：基于互联网}

\subsubsection{私有云：基于VPN}

\subsection{云客户端前端}
\subsubsection{图形用户界面}

\subsubsection{手机GUI}

\subsubsection{电脑GUI}

\subsection{云客户端程序}

\subsubsection{手机APP}
\subsubsection{电脑APP}
\section{迁移数据库}

\subsection{迁移ACCESS数据库到MySQL数据库}
\subsubsection{用例：一次性迁移一个AutoPDMS项目}

\subsubsection{用例：一次性迁移所有AutoPDMS项目}

\subsubsection{用例：用户登录时一次性迁移该AutoPDMS项目}

\section{云设计}

\section{登录方式}

\subsection{用例：AutoPDMS传统登录方式}

\subsection{用例：微信登录方式}

\subsection{用例：QQ登录方式}

\subsection{用例：淘宝网登录方式}

\subsection{用例：Facebook登录方式}


\section{即时通信}

\section{分享屏幕}


\section{审核方案}


\section{培训用户}


\section{升级软件}

\part{功能需求总结}
\section{电站管道实时监控系统\label{pipeScada}}
HQ公司研究院与长沙优易软件开发有限公司(UESOFT)、物联网公司(高总)合作开发电站管道监测系统，实现电站管道位移、应力及稳定性监测功能，同时能够对管道卡涩、管系稳定性及支吊架失效等故障进行自动排查，增强电站安全性。

长沙优易软件开发有限公司(中文简称:优易软件，英文简称:UESOFT)是三维工厂设计管理系统软件开发商，也是新一代三维数据CAD/CAE集成设计和仿真平台开创者。公司开发的自主知识产权的管道应力分析软件AutoPSA居于中国市场前2名。UESOFT于2000年10月23日经湖南省长沙市工商行政管理局(现市场监督管理局)核准登记设立。
长沙优易软件开发有限公司(UESOFT)开发的三维数据CAD/CAE集成设计和仿真平台AutoPDMS为设计人员提供了统一的设计环境。AutoPDMS集成了设计库(配管Piping、设备Equipment、暖通空调HVAC、支吊架H\&S、电缆桥架cabletray、钢结构Steel、结构Structure、建筑Architecture、房屋Building、机电管MEP、机械Mechanical、电气Electrical)、构造元件库和构造等级库(Paragon \& Specon)、管段图SPOOL、轴测图Isodraft、投影图DRAFT、模型转换(导出PDMS模型到AutoPDMS)、权限管理Admin、多用户协同设计、渲染、网格Mesh、有限元FEM、应力分析、结构分析、流体分析、电磁场分析、多物理场分析等。AutoPDMS是一套使用STL、BOOST、MFC、ObjectARX、ZRX、GRX、OpenSceneGraph、OpenGL写成的C++类库。
UESOFT以创新技术为工业与民用行业开发三维协同设计管理系统和CAD/CAE集成设计和仿真软件，致力于为各专业如机械、电气、管道、设备、建筑、结构、工程分析等领域的设计、制造、工程、采购、施工、运营、退役全生命周期提供集成解决方案。UESOFT产品包括CAD/CAE集成设计和仿真平台和协同三维工厂设计管理系统软件如管道、支吊架、设备、暖通空调HVAC、电缆托架、建筑、结构、 机械、电气、管道有限元应力分析、管网流体分析软件等。至2020年10月23日，拥有中国能建、中国电建、中国节能、中国华电、国家电投、中国石化、中国石油、中海油、中国化工、中国医药、国家电网、南方电网、中粮、保利、中轻、中盐、中化、中机、中钢、中国五矿、中冶、中色、中煤、中材、中核、中广核、中船重工、中交、中铁、中航、中信、中国建筑、中国建设科技、中国兵器、中国通用、中烟、东方电气、华润、恩菲、瑞林、中赟、天辰、新奥燃气、杭氧股份、三峰卡万塔、桑德环境、三一重装等正版用户558家。UESOFT也投资于研发数值仿真软件或嵌入式软件。
UESOFT还对可再生能源和节能减排领域如太阳能冷热电装置 、生物质秸秆气化冷热电机组MCHP、垃圾气化发电装置、微型风能发电装置、空气能加热制冷装置 、余热发电系统、燃气蒸汽联合循环系统、生物质能源与化工分布式全自动微型工厂系统、太阳热发电系统、智能家电或智能设备、各频段数据通讯系统等进行研发投资，开发分布式微型能源系统和余热利用能源系统、生物质能源与化工系统。UESOFT也投资于研发各种开源或闭源系统，包括嵌入式系统(Embedded System)、移动互联网或物联网(IOT)等。
UESOFT公司采用各种敏捷项目管理方法如测试驱动开发TDD(Test-Driven Development)、极限编程XP、结对编程PP、迭代SCRUM等方法管理各种开发项目。公司采用员工创业绩效管理体系，或岗位固定比例提成奖励体系或功能点分析绩效管理体系、自由竞争绩效管理体系，诚信公正评价反馈员工贡献。
公司坚持“创造简易，服务人类，追求卓越，永无止境”的企业精神，努力营造认真负责、团结和谐、开拓创新、锐意进取的企业环境，为全体员工提供良好的发展平台。公司长期致力于CAD/CAE/ERP/IOT集成系统软件的开发，为中国和全球客户提供优秀、易用、全面的解决方案。

UESOFT与其它公司合作方案：

合作公司G(可以从UESOFT雇佣程序员)使用C/C++语言将物联网系统S集成在AutoPDMS for Internet中，并负责全部开发和运营费用，及将销售额10\%提成给UESOFT公司。UESOFT可以投资现金给合作公司G，公司G在成功销售系统S后应逐步归还UESOFT这些投资额本金和利息(月息1\%)。

www.uesoft.com
QQ:1326652418
\subsection{模型数据输入与采集}
HQ公司：
\subsubsection{管道模型和边界条件数据}
应用优易软件建立电站管道模型，给定边界条件及支吊架位置信息；
\subsubsection{传感器单片机内部数据转换}
把传感器ADC采样的数据在传感器CPU处理，转换为物理数据。
\subsubsection{发送器单片机数据发送}
使用无线协议发送传感器的数据。
\subsubsection{无线采集器单片机数据接收}
使用无线协议接收传感器发送的数据。
\subsubsection{传感器数据转换}
采用先进传感器分析管道支吊架与管道连接位置的六个自由度位移和转角；
\subsubsection{传感器数据传输}
通过无线采集器传输至地面服务器内；
\subsubsection{设置温度与位移对应关系}
给定在不同温度下各支吊架设计位移。

以下需求由UESOFT实现。
\subsection{时序数据库}
选型与集成。
\subsection{模型数据接口}
\subsubsection{传感器数据采样}
采样接收无线采集器传输过来的六自由度数据，采样周期T可调，暂定T=5min(五分钟)。

\subsubsection{传感器数据和UE实时数据库URDB接口}
采样数据在内存对象中，可利用持久层保存到实时数据库：SQL或NoSQL数据库、Redis数据库、InfluxDB时序数据库，等等。
\subsection{模型数据实时设置}
根据某时刻管内蒸汽温度选择支吊架设计位移(可在管道端点和附着在大刚度物体上的支吊点设置附加位移，不应在其它支吊点设置附加位移)，设置计算工况。
\subsection{模型数据计算}
调用有限元分析程序如AutoPSA等得到计算结果。
\subsection{传感器测量数据与计算结果不一致的原因}
使用有限元分析程序计算的应力与实际应力差值为什么较大，超出预期值？有如下原因：
\subsubsection{传感器测量数据误差}
传感器测量数据误差，包括但不限于传感器损坏或故障、传感器测量稳定性差、传感器精度差、传感器内部代码BUG等。
\subsubsection{有限元程序代码BUG误差}
有限元程序代码BUG误差，如前处理代码BUG，算法代码BUG，后处理代码BUG，等。
\subsubsection{模型原始数据误差\label{modelrawdataerrror}}
模型原始数据误差包括但不限于：
材料特性误差，如密度、弹性模量、热膨胀系数等误差。
几何模型误差，如管道直径和壁厚尺寸误差，阀门重量误差，等。
边界条件误差，如约束设置误差，双向间隙位移误差，摩擦系数误差，弹簧刚度误差，弹簧卡死，恒力弹簧特性误差，等。
\subsection{使传感器测量数据与计算结果一致}
在排除传感器误差和有限元程序代码BUG误差情况下，通过深度学习或人工智能处理，有可能获得准确的\ref{modelrawdataerrror}这些数值，使得应力计算结果与传感器测量值一致。
\subsection{测量与计算对比分析}
对比设计应力与实际应力差值，将计算结果在管系模型中展示，并输出管系卡涩或失效位置结论。
\subsection{显示和输出}
建立列表，实现采集器六自由度数据存储及查询功能，能够以时间为横轴输出各支吊架位移及应力图表。
\section{UE云平台}
UESOFT提供云计算系统，传感器数据存储到云计算平台。
\subsection{云服务器}
\subsubsection{私有云：基于局域网}
\subsubsection{公有云：基于互联网}
\subsubsection{私有云：基于VPN}
\subsection{云客户端后台}
云客户端后台服务访问服务器数据。
\subsubsection{私有云：基于局域网}
\subsubsection{公有云：基于互联网}
\subsubsection{私有云：基于VPN}
\subsection{云客户端前端}
\subsubsection{图形用户界面}
图形用户界面(GUI)用于人机交互，用户使用GUI输入或显示\ref{pipeScada}各种数据。
\subsubsection{手机GUI}
手机屏幕较小，分辨率较高，手机GUI有特殊的大小、长宽。
\subsubsection{电脑GUI}
电脑屏幕较大，分辨率较高，电脑GUI有特殊的大小、长宽。
\subsection{云客户端程序}
云客户端程序由云客户端前端和后台服务组合而成。根据终端不同，分成手机APP和电脑APP或平板APP等。
\subsubsection{手机APP}
\subsubsection{电脑APP}
\section{实时数据库}
实时数据库（RTDB－Real Time DataBase）是数据库系统发展的一个分支，是数据库技术结合实时处理技术产生的，可直接实时采集、获取企业运行过程中的各种数据，并将其转化为对各类业务有效的公共信息。

实时数据库系统是开发实时控制系统、数据采集系统、CIMS系统等的支撑软件。在流程行业中，大量使用实时数据库系统进行控制系统监控，系统先进控制和优化控制，并为企业的生产管理和调度、数据分析、决策支持及远程在线浏览提供实时数据服务和多种数据管理功能。实时数据库已经成为企业信息化的基础数据平台，可直接实时采集、获取企业运行过程中的各种数据，并将其转化为对各类业务有效的公共信息，满足企业生产管理、企业过程监控、企业经营管理之间对实时信息完整性、一致性、安全共享的需求，可为企业自动化系统与管理信息系统间建立起信息沟通的桥梁。帮助企业的各专业管理部门利用这些关键的实时信息，提高生产销售的营运效率。
实时数据库的一个重要特性就是实时性，包括数据实时性和事务实时性。数据实时性是现场IO数据的更新周期，作为实时数据库，不能不考虑数据实时性。一般数据的实时性主要受现场设备的制约，特别是对于一些比较老的系统而言，情况更是这样。事务实时性是指数据库对其事务处理的速度。它可以是事件触发方式或定时触发方式。事件触发是该事件一旦发生可以立刻获得调度，这类事件可以得到立即处理，但是比较消耗系统资源；而定时触发是在一定时间范围内获得调度权。作为一个完整的实时数据库，从系统的稳定性和实时性而言，必须同时提供两种调度方式。
针对不同行业不同类型的企业，实时数据库的数据来源方式也各不相同。总的来说数据的主要来源有DCS控制系统、由组态软件+PLC建立的控制系统、数据采集系统（SCADA）、关系数据库系统、直接连接硬件设备和通过人机界面人工录入的数据。根据采集的方式方法可以分为：支持OPC协议的标准OPC方式、支持MODBUS协议的标准MODBUS通信方式、通过ODBC协议的ODBC通信方式、通过API编写的专有通信方式、通过编写设备的专有协议驱动方式等。
\subsection{实时数据库系统选型}
北京华恒信远拥有丰富国外各种主流实时数据库软件实施经验，根据系统集成商的项目实际要求，提供实时数据库选型咨询，目前国内外实时数据库分为四种类型：一种是国外传统实时数据库、国外组态软件供应商实时数据库、国内传统实时数据库和国内组态软件供应商实时数据库，下面分别介绍以上四种类型的实时数据库：
\subsubsection{国外传统实时数据库}
包括：
a. OSI公司的PI( Plant Information System )
b. Aspen公司的IP21( InfoPlus.21 )
c. Honeywell公司的PHD( Process History Database )
d. Instep公司的eDNA(enterprise Distributed Network Architecture) 

PI在国内广泛应用于电力行业，它采用了旋转门压缩专利技术和独到的二次过滤技术，使进入到PI数据库的数据经过了最有效的压缩，极大地节省了硬盘空间；IP21和PI一样属于正宗的实时数据库软件，价格和PI差不多，比较昂贵，IP21在中石油、中石化内部得到了广泛使用；由于Honeywell占据了化工行业DCS大部分份额，因此PHD在化工行业使用得也比较广泛，PHD在内部使用了Oracle关系数据库；
以上三种实时数据库均为二十世纪末推出来的传统实时数据库，由于在电力行业占垄断地位的PI价格居高不下，Instep eDNA凭借价格优势进入了电力行业，逐渐拥有了一定的客户，因此目前大型电力企业仍然偏爱OSI PI，不少中小电力企业则选择了eDNA。 
特点：价格高、实时数据库包含实时数据库及其它配套软件。
\subsubsection{国外组态软件供应商实时数据库}
a. Wonderware公司的Historian( 原InSQL)
b. GE Fanuc公司的iHistorian
c. Rockwell公司的RSSQL
d. Siemens公司的SIMATIC-IT-Historian
由于Wonderware的组态软件Intouch在国内工控业界的普遍使用，尤其在钢铁行业的广泛使用，因此Wonderware Historian(原InSQL)在钢铁行业占有较大的市场，Wonderware Historian在内部使用了MS SQL Server关系数据库,相对前三种实时数据库，Wonderware Historian进入实时数据库市场较晚，相对易学易用，价格偏低，实际项目中Wonderware Historian还和Intouch、APlication Server等Wonderware软件配合使用。
GE Fanuc iHistorian是GE公司推出的实时数据库软件，它和Wonderware Historian类似，不过内核没有关系数据库，第三方应用程序主要通过API进行数据访问。
目前国内系统集成商使用Rockwell公司的RSSQL和Siemens公司的SIMATIC-IT-Historian还较少，一般都是该类公司在各自的企业信息化项目中使用。
特点：价格适中、但实时数据库只包含历史数据库，实时数据库其它配套软件（比如Wonderware IDAS、Intouch和Application等）根据项目实际情况需要另外购买。
\subsubsection{国内传统实时数据库}
a. 北京华恒信远科技有限公司EI
b. 北京和利时信息技术有限公司HiRIS
c. 浙江中控软件技术有限公司ESP-iSYS
d. 上海麦杰科技有限责任公司OpenPlant
特点：该类公司大都在通过大量的实时数据库工程实施经验、掌握吸收国外传统实时数据库的基础上开发而成各自的实时数据库产品。
价格较低，实时数据库包含实时数据库及其它配套软件，由于实时数据库市场没有组态软件市场那样大，因此，该类产品均没有得到广泛的推广，一般都是本公司做与实时数据库相关的项目时配套使用，系统集成商购买该软件做项目的较少，即使有也是通过项目合作的方式进行。
\subsubsection{国内组态软件供应商实时数据库}
a. 北京亚控科技发展有限公司KingRDB
b. 北京三维力控科技有限公司pSpace
c. 紫金桥软件技术有限公司RealDB
特点：该类公司大都在通过积累组态软件开发及应用经验基础上开发而成的实时数据库产品。
价格低，实时数据库其它配套软件根据项目实际情况需要另外购买。由于该类公司的组态软件市场广泛、客户多、价格便宜，因此，该类公司开发的实时数据库产品价格一般也都相对很便宜，但一般该类公司自己不做项目，大都是系统集成商购买该软件做项目。
\section{ 时序数据库排名}
K-V数据库排名前10的品牌如下，Redis优势还是明显：

文档数据库排名前10的品牌如下，MongoDB还是遥遥领先：

时序数据库是应对物联网出现的新品类数据库，正处于市场的上升期，目前的应用还处于初级阶段：

各类型数据库，占市场分割如下如所示，关系数据库，文档数据库和k-v数据库还是应用最广泛的数据库类型。

最近两年来，各类型数据库的市场变动情况如下图所示，可以看出来，近两年来，时序数据库的应用增长非常迅速，这也是市场对拥抱物联网产业的具体表现，未来，时序数据库还将有更大的增长。
\section{时序数据库}
2017年2月Facebook开源了beringei时序数据库；到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了，而早在2016年7月，百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB，成为支持其发展制造，交通，能源，智慧城市等产业领域的核心产品，同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务，业界的频频发声，正说明各家企业已经迫不及待的拥抱物联网时代的到来。

本文会从时序数据库的基本概念、使用场景、解决的问题一一展开，最后会从如何解决时序数据存储这一技术问题入手进行深入分析。
\subsection{背景}
百度无人车在运行时需要监控各种状态，包括坐标，速度，方向，温度，湿度等等，并且需要把每时每刻监控的数据记录下来，用来做大数据分析。每辆车每天就会采集将近8T的数据。如果只是存储下来不查询也还好（虽然已经是不小的成本），但如果需要快速查询“今天下午两点在后厂村路，速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询，那么时序数据库会是一个很好的选择。
\subsection{什么是时序数据库}
先来介绍什么是时序数据。时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习，实现预测和预警。

时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。

对比传统数据库仅仅记录了数据的当前值，时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。



时序数据示例



p1-北上广三地2015年气温变化图



p2-北上广三地当前温度实时展现



下面介绍下时序数据库的一些基本概念（不同的时序数据库称呼略有不同）。

metric: 度量，相当于关系型数据库中的table。

data point: 数据点，相当于关系型数据库中的row。

timestamp：时间戳，代表数据点产生的时间。

field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。

tag: 标签，或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key。

如下图，度量为Wind，每一个数据点都具有一个timestamp，两个field：direction和speed，两个tag：sensor、city。它的第一行和第三行，存放的都是sensor号码为95D8-7913的设备，属性城市是上海。随着时间的变化，风向和风速都发生了改变，风向从23.4变成23.2；而风速从3.4变成了3.3。



p3-时序数据库基本概念图
\subsection{ 时序数据库的场景}
所有有时序数据产生，并且需要展现其历史趋势、周期规律、异常性的，进一步对未来做出预测分析的，都是时序数据库适合的场景。

在工业物联网环境监控方向，百度天工的客户就遇到了这么一个难题，由于工业上面的要求，需要将工况数据存储起来。客户每个厂区具有20000个监测点，500毫秒一个采集周期，一共20个厂区。这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte，数据总量将达1P（如果每台服务器10T的硬盘，那么总共需要100多台服务器）。这些数据不只是要实时生成，写入存储；还要支持快速查询，做可视化的展示，帮助管理者分析决策；并且也能够用来做大数据分析，发现深层次的问题，帮助企业节能减排，增加效益。最终客户采用了百度天工的时序数据库方案，帮助他解决了难题。

在互联网场景中，也有大量的时序数据产生。百度内部有大量服务使用天工物联网平台的时序数据库。举个例子，百度内部服务为了保障用户的使用体验，将用户的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析，尽早的发现、解决问题，保证用户的使用体验。
\subsection{ 时序数据库遇到的挑战}
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题，但少量数据是展现的纬度有限，细节少，可置信低，更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。

可以看到时序数据库需要解决以下几个问题

l   时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。

l   时序数据的读取：又如何支持在秒级对上亿数据的分组聚合运算。

l   成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。

这些问题不是用一篇文章就能含盖的，同时每个问题都可以从多个角度去优化解决。在这里只从数据存储这个角度来尝试回答如何解决大数据量的写入和读取。
\subsection {数据的存储}
数据的存储可以分为两个问题，单机上存储和分布式存储。
单机存储

如果只是存储起来，直接写成日志就行。但因为后续还要快速的查询，所以需要考虑存储的结构。

传统数据库存储采用的都是B tree，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上，导致速度很慢。我们知道SSD具有更快的寻道时间，但并没有从根本上解决这个问题。

对于90\%以上场景都是写入的时序数据库，B tree很明显是不合适的。

业界主流都是采用LSM tree替换B tree，比如Hbase, Cassandra等nosql中。这里我们详细介绍一下。

LSM tree包括内存里的数据结构和磁盘上的文件两部分。分别对应Hbase里的MemStore和HLog；对应Cassandra里的MemTable和sstable。

LSM tree操作流程如下：

1.     数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。

2.     内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。

3.     随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。



p4-Hbase LSM tree结构介绍（注1）

可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。但同时也牺牲了读取性能，因为同一个key的值可能存在于多个HFile中。为了获取更好的读取性能，可以通过bloom filter和compaction得到，这里限于篇幅就不详细展开。
分布式存储

时序数据库面向的是海量数据的写入存储读取，单机是无法解决问题的。所以需要采用多机存储，也就是分布式存储。

分布式存储首先要考虑的是如何将数据分布到多台机器上面，也就是 分片（sharding）问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。



分片方法

时序数据库的分片方法和其他分布式系统是相通的。

哈希分片：这种方法实现简单，均衡性较好，但是集群不易扩展。

一致性哈希：这种方案均衡性好，集群扩展容易，只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。

范围划分：通常配合全局有序，复杂度在于合并和分裂。代表有Hbase。



分片设计

分片设计简单来说就是以什么做分片，这是非常有技巧的，会直接影响写入读取的性能。

结合时序数据库的特点，根据metric+tags分片是比较好的一种方式，因为往往会按照一个时间范围查询，这样相同metric和tags的数据会分配到一台机器上连续存放，顺序的磁盘读取是很快的。再结合上面讲到的单机存储内容，可以做到快速查询。

进一步我们考虑时序数据时间范围很长的情况，需要根据时间范围再将分成几段，分别存储到不同的机器上，这样对于大范围时序数据就可以支持并发查询，优化查询速度。

如下图，第一行和第三行都是同样的tag（sensor=95D8-7913;city=上海），所以分配到同样的分片，而第五行虽然也是同样的tag，但是根据时间范围再分段，被分到了不同的分片。第二、四、六行属于同样的tag（sensor=F3CC-20F3;city=北京）也是一样的道理。



p5-时序数据分片说明
\subsection{真实案例}
下面以一批开源时序数据库作为说明。

InfluxDB:

非常优秀的时序数据库，但只有单机版是免费开源的，集群版本是要收费的。从单机版本中可以一窥其存储方案：在单机上InfluxDB采取类似于LSM tree的存储结构TSM；而分片的方案InfluxDB先通过<database>+<timestamp>（事实上还要加上retentionPolicy）确定ShardGroup，再通过<metric>+<tags>的hash code确定到具体的Shard。

这里timestamp默认情况下是7天对齐，也就是说7天的时序数据会在一个Shard中。



p6-Influxdb TSM结构图（注2）



Kairosdb:

底层使用Cassandra作为分布式存储引擎，如上文提到单机上采用的是LSM tree。

Cassandra有两级索引：partition key和clustering key。其中partition key是其分片ID，使用的是一致性哈希；而clustering key在一个partition key中保证有序。

Kairosdb利用Cassandra的特性，将 <metric>+<timestamp>+<数据类型>+<tags>作为partition key，数据点时间在timestamp上的偏移作为clustering key，其有序性方便做基于时间范围的查询。

partition key中的timestamp是3周对齐的，也就是说21天的时序数据会在一个clustering key下。3周的毫秒数是18亿正好小于Cassandra每行列数20亿的限制。



OpenTsdb:

底层使用Hbase作为其分布式存储引擎，采用的也是LSM tree。

Hbase采用范围划分的分片方式。使用row key做分片，保证其全局有序。每个row key下可以有多个column family。每个column family下可以有多个column。



上图是OpenTsdb的row key组织方式。不同于别的时序数据库，由于Hbase的row key全局有序，所以增加了可选的salt以达到更好的数据分布，避免热点产生。再由与timestamp间的偏移和数据类型组成column qualifier。

他的timestamp是小时对齐的，也就是说一个row key下最多存储一个小时的数据。并且需要将构成row key的metric和tags都转成对应的uid来减少存储空间，避免Hfile索引太大。下图是真实的row key示例。



p7-open tsdb的row key示例（注3）
\subsection {结束语}
可以看到各分布式时序数据库虽然存储方案都略有不同，但本质上是一致的，由于时序数据写多读少的场景，在单机上采用更加适合大吞吐量写入的单机存储结构，而在分布式方案上根据时序数据的特点来精心设计，目标就是设计的分片方案能方便时序数据的写入和读取，同时使数据分布更加均匀，尽量避免热点的产生。

数据存储是时序数据库设计中很小的一块内容，但也能管中窥豹，看到时序数据库从设计之初就要考虑时序数据的特点。后续我们会从其他的角度进行讨论。
\section{腾讯时序数据库：CTSDB解密}
腾讯技术工程 | 腾讯唯一时序数据库：CTSDB解密
腾讯技术
关注
1人评论
2308人阅读
2018-02-01 15:33:44
背景：随着互联网的高速发展、大数据的迅速膨胀和物联网的飞速崛起，我们发现生活和工作中的大部分数据渐渐和时间产生了关联。比如微信运动的实时步数、股票每天的收盘价格、共享单车的设备状态等等。为了存储这些与时间相关的数据，积极拥抱物联网时代，各大企业纷纷推出自家的时序数据库。本文将对时序数据库的基本概念、应用场景及腾讯时序数据库CTSDB做简要介绍。

\subsection{什么是时序数据库}
\subsubsection{时序数据}
1.1 什么是时序数据？

在引入时序数据库之前，先要了解“时序数据”的概念：按照时间顺序记录系统、设备状态变化的数据被称为时序数据（TimeSeries Data）。它普遍存在于IT基础设施、运维监控系统和物联网中。


时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律。其意义体现在两方面：


（1）从时间轴往后看，时序数据可做成报表，观测数据变化规律、捕获异常。这里举两个例子：
下图为共享单车在旧金山某热门区域的每小时车辆的借还数量。通过分析该区域车辆数目的历史数据，单车公司可得知热点借车时间段是否需要车辆补给。

1.jpg



下图为某互联网服务的出入流量历史记录。从图中可以明显看到入流量（蓝色线）在某时间段有毛刺，服务提供商可基于此段时间排查服务有无异常。也可以进一步基于流量监控做告警，使运维人员能够及时处理线上问题。

2.jpg


（2）从时间轴向前看，时序数据可以建立数学模型、做统计分析，预测事物发展趋势。
举例，下图为联合国在2015年分析过往人口增长趋势后，发布的人口数字及预测报告。从图中可以看出未来非洲人口将持续增长，这是任何一个跨国企业都不该忽略的市场，也预示着当地政府面临重大挑战。

3.jpg


1.2 时序数据的数学模型

上面介绍了时序数据的基本概念，也说明了分析时序数据的意义。那么时序数据该怎样存储呢？数据的存储要考虑其数学模型和特点，时序数据当然也不例外。所以这里先介绍时序数据的数学模型和特点。

下图为一段时序数据，记录了一段时间内的某个集群里各机器上各端口的出入流量，每半小时记录一个观测值。这里以图中的数据为例，介绍下时序数据的数学模型（不同的时序数据库中，基本概念的称谓有可能不同，这里以腾讯CTSDB为准）：

metric： 度量的数据集，类似于关系型数据库中的 table；

point： 一个数据点，类似于关系型数据库中的 row；

timestamp： 时间戳，表征采集到数据的时间点；

tag： 维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；

field： 指标列，代表数据的测量值，随时间平滑波动，不需要查询。

4.jpg


如上图所示，这组数据的metric为Network，每个point由以下部分组成：

timestamp：时间戳

两个tag：host、port，代表每个point归属于哪台机器的哪个端口

两个field：bytes\_in、bytes\_out，代表piont的测量值，半小时内出入流量的平均值

同一个host、同一个port，每半小时产生一个point，随着时间的增长，field（bytes\_in、bytes\_out）不断变化。如host：host4，port：51514，timestamp从02:00 到02:30的时间段内，bytes\_in 从 37.937上涨到38.089，bytes\_out从2897.26上涨到3009.86，说明这一段时间内该端口服务压力升高。


1.3 时序数据特点

数据模式： 时序数据随时间增长，相同维度重复取值，指标平滑变化：这点从上面的Network表的数据变化可以看出。

写入： 持续高并发写入，无更新操作：时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入（如摩拜单车2017年全国车辆数为千万级），但数据大多表征设备状态，写入后不会更新。

查询： 按不同维度对指标进行统计分析，且存在明显的冷热数据，一般只会频繁查询近期数据。

\subsubsection{时序数据库}

有了时序数据后，该存储在哪里呢？首先我们看下传统的解决方案在存储时序数据时会遇到什么问题。


2.1 传统解决方案

时序数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。传统的时序数据解决方案主要有两种：关系型数据库（MySQL）、Hadoop生态。

·        MySQL：在海量的时序数据场景下存在如下问题

存储成本大：对于时序数据压缩不佳，需占用大量机器资源；

维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；

写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；

查询性能差：适用于交易处理，海量数据的聚合分析性能差。

·        Hadoop生态（Hadoop、Spark等）

数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；

查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。

2.2 时序数据库

时序数据库是管理时序数据的专业化数据库，并针对时序数据的特点对写入、存储、查询等流程进行了优化，这些优化与时序数据的特点息息相关：

1) 存储成本：

利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；

通过预降精度，对历史数据做聚合，节省存储空间。

2)  高并发写入：

批量写入数据，降低网络开销；

数据先写入内存，再周期性的dump为不可变的文件存储。

3)  低查询延时，高查询并发：

优化常见的查询模式，通过索引等技术降低查询延时；

通过缓存、routing等技术提高查询并发。


2.3 开源时序数据库对比

目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其产品特性对比如下图所示：

5.jpg



从上表可以看出，开源的时序数据库存在如下问题：

没有free、易用的分布式版本（OpenTSDB支持分布式部署，但依赖系统过多，维护成本高）；

聚合能力普遍较弱，而时序数据大多需要来做统计分析；

没有free的权限管理；

没有针对时间序列的多维度对比分析工具。
\subsection{CTSDB}
腾讯CTSDB（Cloud Time Series Database）是一种分布式、高性能、多分片、自均衡的时序数据库，针对时序数据的高并发写入、存在明显的冷热数据、IoT用户场景等做了大量优化，同时也支持各行业的日志解析和存储，其架构如下图所示。

6.jpg


1. CTSDB主要特点

1)  高性能：（具体性能数据将在后文给出）

支持批量写入、高并发查询；

通过集群扩展，随时线性提升系统性能；

支持sharding、routing，加速查询。

2)  高可靠：

支持多副本；

机架感知，自动错开机架分配主从副本。

3)  易使用：

丰富的数据类型，REST接口，数据写入查询均使用json格式；

原生分布式，弹性可伸缩，数据自动均衡；

4)  低成本：

支持列存储，高压缩比（0.1左右），降低存储成本；

支持数据预降精度：降低存储成本的同时，提高查询性能。

副本数可按需调整。

5)  强大的聚合能力：

max,min,avg,percentile,sum,count,group by等常用聚合；

复杂的脚本聚合（例如可对多字段间的计算结果做聚合）；

时间区间聚合、GEO聚合、嵌套聚合。

6)  亮点能力:

数据监控告警：对存入数据进行数据量、字段统计、基线对比等监控，通过微信、短信、邮件告警；

权限系统：支持用户名密码、机器白名单的权限系统；

数据时效性：支持数据过期删除；

数据导出。


2. 竞品性能对比测试

这里选用业界较为流行的InfluxDB来与CTSDB做性能对比测试。


2.1 测试场景

CTSDB与InfluxDB对比测试：CTSDB与InfluxDB均单节点部署，单节点占用24个cpu核心，128g内存，万兆网卡,，磁盘SSD RAID0。


CTSDB单节点集群与双节点集群对比测试：用以验证CTSDB的线性扩展能力。


2.2 写入性能测试

数据样例：

导入的数据由InfluxDB的官方测试工具产生，https://github.com/influxdata/influxdb-comparisons。

数据为若干host的时序数据，每个point包含10个tag（均为string类型），10个filed（均为float类型），timestamp为时间戳（一个host每10秒一个点）。

样例如下所示：

7.jpg


测试结果：
(1) CTSDB单节点集群与InfluxDB单机版写入性能对比

8.jpg

横坐标：并发数（写入线程数），纵坐标：QPS（单位：万次/s）


结论:CTSDB单节点写入性能最高在19w，InfluxDB在1。


(2) CTSDB单节点集群与CTSDB双节点集群写入性能对比

9.jpg

横坐标：并发数（写入线程数），纵坐标：QPS（单位：万次/s）


结论:CTSDB单节点集群写入最高可达20w，双节点集群写入性能34w。


2.3 查询性能测试

查询样例：

这里以CTSDB的查询语句为例：

10.jpg


查询语句解读：
取出1个host的全量数据，然后任取一个小时做过滤后，按分钟粒度分桶（groupby，最终结果有60个桶），最后输出所有的桶，并计算桶内所有数据的usage\_user字段最大值 。

注意这里的查询使用了CTSDB的routing功能，用以加速查询。

查询结果样例：

11.jpg


测试结果：

(1) CTSDB单节点集群与InfluxDB单机版查询性能对比

12.jpg

横坐标：并发数（查询线程数），纵坐标：QPS（单位：次/s）

结论：CTSDB查询性能整体比InfluxDB好很多，当并发数较高时（40），CTSDB查询性能比InfluxDB高出近4倍，在2w左右。在并发线程数达到50时，InfluxDB出现链接错误，拒绝查询请求；此时，CTSDB可正常查询。


(2) CTSDB单节点集群与双节点集群查询性能对比

13.jpg

横坐标：并发数（查询线程数），纵坐标：QPS（单位：次/s）



结论：在并发数较高的情况下，双节点集群查询性能较单节点集群有了大幅度提升，呈现了查询性能线性扩展的趋势。


\subsection{关于我们}
\subsubsection{我们的现状}

作为腾讯唯一的时序数据库，CTSDB支撑了腾讯内部20多个核心业务（微信×××、财付通、云监控、云数据库、云负载等）。其中，云监控系统的记录了腾讯内部各种软硬件系统的实时状态，CTSDB承载了它所有的数据存储，在每秒千万级数据点的写入压力、每天20TB+数据量的写入场景下稳定运行，足以证明CTSDB可以稳定支撑物联网的海量数据场景。

\subsubsection{我们的未来}

14.jpg

CTSDB即将在腾讯云正式上线，为物联行业提供技术服务！我们将在降低存储成本、提升易用性和丰富功能性等方面进一步优化CTSDB！欢迎对时序数据库和分布式存储感兴趣的同学加入我们！
\section{K-V键值对数据库}
\subsection{K-V键值对数据库}
作者：@houkai
本文为作者原创，转载请注明出处：https://www.cnblogs.com/houkai/p/4689912.html
\subsubsection{Zookeeper}
现在的KV存储系统都是分布式的，首先介绍Zookeeper——针对大型分布式系统的高可靠的协调系统。

开发分布式系统是件很困难的事情，其中的困难主要体现在分布式系统的“部分失败”。“部分失败”是指信息在网络的两个节点之间传送时候，如果网络出了故障，发送者无法知道接收者是否收到了这个信息，而且这种故障的原因很复杂，接收者可能在出现网络错误之前已经收到了信息，也可能没有收到，又或接收者的进程死掉了。

Zookeeper就是解决分布式系统“部分失败”的框架，当分布式系统碰到部分失败时候，可以正确的处理此类的问题，让分布式系统能正常的运行。zookeeper的实际运用场景：

集群中有服务器挂掉时，能检测到并将其从列表中删除，并能报告给管理员；当master挂掉时，会根据”选举领导者算法”选出新的健康的master；
分布式锁机制，保证集群中数据的一致性；
配置管理，快速地配置集群；
任务均衡等。
\subsubsection{memcached}

许多Web应用都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。 但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响。memcached是高性能的分布式内存缓存服务器。 一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、 提高可扩展性。
NewImage

特点是：协议简单、基于libevent的事件处理、内置内存存储方式、memcached不互相通信的分布式。

由于数据仅存在于内存中，因此重启memcached、重启操作系统会导致全部数据消失。 另外，内容容量达到指定值之后，就基于LRU(Least Recently Used)算法自动删除不使用的缓存。 memcached本身是为缓存而设计的服务器，因此并没有过多考虑数据的永久性问题。 各个memcached不会互相通信以共享信息，分布策略由客户端实现。
\subsubsection{HBase}

HBase是Apache Hadoop中的一个子项目，Hbase依托于Hadoop的HDFS作为最基本存储基础单元，通过使用hadoop的DFS工具可以看到这些数据存储文件夹的结构，还可以通过Map/Reduce的框架(算法)对HBase进行操作（Hive更常用），如图所示：

NewImage 

HBase在产品中还包含了Jetty，在HBase启动时采用嵌入式的方式来启动Jetty，因此可以通过web界面对HBase进行管理和查看当前运行的一些状态，非常轻巧。

HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。所谓非结构化数据存储就是说HBase是基于列的而不是基于行的模式。HBase是介于Map Entry(key \& value)和DB Row之间的一种数据存储方式。就点有点类似于Memcache，但不仅仅是简单的一个key对应一个 value，你很可能需要存储多个属性的数据结构，但没有传统数据库表中那么多的关联关系，这就是所谓的松散数据。

一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的，因此用户可以给行定义各种不同的列，对于这样的功能在大项目中非常实用，可以简化设计和升级的成本。 
\subsubsection{Tair}

tair是淘宝自己开发的一个分布式 key/value存储引擎。tair分为持久化和非持久化两种使用方式，非持久化的tair可以看成是一个分布式缓存；持久化的tair将数据存放于磁盘中，为了解决磁盘损坏导致数据丢失，tair可以配置数据的备份数目，tair自动将一份数据的不同备份放到不同的主机上，当有主机发生异常，无法正常提供服务的时候，其于的备份会继续提供服务。tair是加强版的memcached，提供了数据长期保存的策略。

tair作为一个分布式系统，是由一个中心控制节点和一系列的服务节点组成。我们称中心控制节点为config server，服务节点是data server。config server负责管理所有的data server，维护data server的状态信息。data server对外提供各种数据服务，并以心跳的形式将自身状况汇报给config server。config server是控制点，而且是单点，目前采用一主一备的形式来保证其可靠性。所有的 data server 地位都是等价的，tair支持自定义的备份数。

Structure

tair的分布采用的是一致性哈希算法，对于所有的key，分到Q个桶中，桶是负载均衡和数据迁移的基本单位。config server根据一定的策略把每个桶指派到不同的data server上，因为数据按照key做hash算法，所以可以认为每个桶中的数据基本是平衡的。保证了桶分布的均衡性，就保证了数据分布的均衡性。

Interface
\subsubsection{redis}
Redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。

与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件（RDB和AOF两种方式），并且在此基础上实现了master-slave(主从)同步。Redis数据库

KV系统对比：Redis/HBase/Tair比较

\subsection{最快的KVS数据库Anna}
伯克利推出世界最快的KVS数据库Anna：秒杀Redis和Cassandra

2018-3-15 17:08| 发布者: 炼数成金\_小数| 查看: 26820| 评论: 0|来自: AI前线
摘要: Anna 的性能和伸缩性主要归功于它的完全无协调机制，节点工作进程有 90\% 的工作负载是在处理请求，而其他大部分系统（如 Masstree 和英特尔的 TBB）只有不到 10\% 的时间在处理请求，它们其余的 90\% 时间花在了等待协 ...

模型 服务器 集群 分布式 Redis
RISE 实验室的前身是赫赫有名的伯克利 AMP 实验室，该实验室曾开发出了一大批大获成功的分布式技术，这些技术对高性能计算产生了深远的影响，包括 Spark、Mesos、Tachyon 等。如今，原 AMP 实验室博士生，同时也是 Spark 和 Mesos 核心作者之一的 Matei 已经转身去了斯坦福，并于去年年底推出了以普及机器学习实践为目的的开源项目 DAWN（详见 AI 前线报道 )，而 RISE 实验室也在没多久后推出了志在取代 Spark 的新型分布式执行框架 Ray（详见 AI 前线报道）。

过去几年，RISE 实验室把研究重点放在如何设计一个无需协调的分布式系统上。他们提出了 CALM 基础理论（http://db.cs.berkeley.edu/papers/sigrec10-declimperative.pdf），设计出了新编程语言 Bloom（http://bloom-lang.net/），开发出了跨平台程序分析框架 Blazes（https://arxiv.org/pdf/1309.3324.pdf），发布了事务协议 HATs（http://www.vldb.org/pvldb/vol8/p185-bailis.pdf）。但在推出 Anna 之前，他们还未就这些理论、语言、框架或协议在多核环境下或云环境中能够提供怎样的性能有过任何测试或评估。

而 Anna 的推出正好印证了他们之前的研究成果。Anna 的论文显示，在单个 AWS 实例上，Anna 的速度是 Redis 的 10 倍。而在一个标准的交互式基准测试中，也以 10 倍的速度打败了 Cassandra。为了获得更多的比较结果，他们还拿 Anna 与其他主流的键值系统进行了性能对比：比 Masstree 快 700 倍，比英特尔的“无锁”TBB 哈希表快 800 倍。当然，Anna 并没有提供类似其他键值系统那样的线性一致性。不过，Anna 使用了本地缓存存放私有状态，仍然提供了极佳的无协调一致性，比“hogwild”风格的 C++ 哈希表要快上 126 倍。而且一旦到了云端，Anna 更是独领风骚，其他的系统无法真正提供线性伸缩，但 Anna 却可以。

Anna 的性能和伸缩性主要归功于它的完全无协调机制，节点工作进程有 90\% 的工作负载是在处理请求，而其他大部分系统（如 Masstree 和英特尔的 TBB）只有不到 10\% 的时间在处理请求，它们其余的 90\% 时间花在了等待协调上。不仅如此，其他系统因为使用了共享内存，还会出现处理器缓存击穿问题。

Anna 不仅速度快，在一致性方面也达到了很高的水准。多年前，他们发布的事务协议 HATs 就已表明，无协调的分布式一致性和事务隔离性存在很大的提升空间，包括级联一致性和读提交事务级别。Anna 将 Bloom 的单格子组合设计模式移植到了 C++ 中，是第一个实现了上述所有级别一致性的系统。当然，也是因为设计上的简洁，才能达到如此快的速度。

RISE 的研究员们在设计 Anna 的过程中学到了很多，它们已经远远超出了一个键值数据库的范畴，可以被应用在任何一个分布式系统上。他们正基于 Anna 开发一个新的扩展系统，叫作 Bedrock。Bedrock 运行在云端，提供了无需人工干预、低成本的键值存储方案，而且是开源的。

Anna 架构简析

图 1：Anna 架构

上图是 Anna 单节点的架构图。Anna 服务器由一系列独立的线程组成，每个线程运行无协调的 actor。每个线程对应一个 CPU 核心，线程数量不超过 CPU 的总核数。客户端代理负责将远程请求分发给 actor，每个 actor 都有一个私有的哈希表，这些哈希表存放在共享内存中。线程间的变更通过内存广播进行交换，而服务器间的变更则通过 protobuf 进行交换。

这种线程和 CPU 核心一对一的模型避免了上下文切换开销。actor 之间不共享键值状态，通过一致性哈希对键空间进行分区，并使用多主复制机制在 actor 之间复制数据分区，而且复制系数是可配置的。actor 基于时间戳将键的更新通知给其他 actor 副本，每个 actor 有自己的私有状态，这个状态保存在一个叫作“格子”的数据结构中，确保在消息发生延迟、重排或重复时仍然能够保证一致性。

Anna 性能评测
下面就 Anna 的无协调 actor 模型在多核 CPU 上的并行能力、多服务器伸缩能力进行评测，并将它与其他流行的键值数据库进行对比。

无协调 actor 模型的伸缩性
在无协调 actor 模型中，每个 actor 对应一个线程，对任何一个共享状态都有自己的一份私有拷贝，并通过异步广播将更新通知给其他 actor。在多核服务器上，这种模型比传统的共享内存模型的性能要高出一个数量级。

为此，RISE 研究员设计了一个对比实验，将 Anna 与其他基于共享内存的 TBB、Masstree 和自己实现的一个键值存储系统（姑且把它叫作“Ideal”）进行了对比。他们在 AWS 的 m4.16xlarge 实例上运行实验，每个实例配备了 32 核的 CPU。实验中使用了 1 百万个键值对，键的大小为 8 字节，值的大小为 1KB。在实验过程中，他们基于 zipfian 分布和各种系数生成不同的压力负载，模拟不同层次的冲突。

在第一次实验中，他们对比了 Anna 与 TBB、Masstree 和 Ideal 在单台服务器上的吞吐量。他们逐渐增加线程数量，直到达到服务器 CPU 核数的上限，并观察它们的吞吐量。

图 2

图 3
图 2 是在高并发情况下，线程数与吞吐量的变化关系，其中 zipf 系数为 4。图 3 是在高并发情况下，CPU 时间的使用情况。CPU 时间被分为 5 类：处理请求（RH）、原子指令（AI）、合并格子（LM）、广播（M）和其他。最右边一栏是 L1 缓存击穿数量（CM）。

从图中可以看出，在这样的负载压力下，TBB 和 Masstree 几乎失去了并行能力。因为大部分是更新操作，针对同一个键值的并行更新操作会被串行化，它们需要同步机制来防止多个线程同时更新同一个键值。因此，随着线程数量的增加，它们性能也只能趋于平缓。Ideal 虽然比 TBB 和 Masstree 的性能高出 6 倍，但相比 Anna，还是差了很多。尽管它没有使用同步机制，但在多个线程修改共享内存地址时，仍然存在缓存一致性方面的开销。

相反，在 Anna 中，更新操作是针对本地状态进行的，不需要进行同步，并定时通过广播进行变更交换。在高并发情况下，尽管它的性能仍然受限于其复制系数，但比基于共享内存的系统要好很多。Anna 有 90\% 的 CPU 时间用于处理请求，花在其他方面的时间则很少。可见，Anna 的无协调 actor 模型解决了键值存储系统在多核环境里的伸缩性难题。

图 4

图 5
图 4 是在低并发情况下，线程数与吞吐量的变化关系，其中 zipf 系数为 0.5。图 5 是在低并发情况下，CPU 时间的使用情况，其中最右边一列表示内存占用（MF）。

当复制系数为 1 时，Anna 因为内存占用率极低而获得了更好的伸缩性。不过，随着复制系数的增加（增加到 3），吞吐量出现了明显下降（下降了四分之三）。这里有两个原因。首先，增加复制系数会占用更多的内存，而且在低并发的情况下，键的更新操作大量增加，所以无法通过合并的方式进行变更交换。图 5 显示，当复制系数为 3 时，Anna 有 69\% 的 CPU 时间用于处理广播变更。而在使用完整的复制系数时，Anna 也停止了伸缩，因为此时相当于每个线程只能处理一个请求。不过，尽管 TBB 和 Masstree 没有广播开销，但在内存占用和同步操作方面仍然存在大量开销。因此，从这个实验中可以得出这样的结论：对于一个支持多主复制的系统来说，在低并发量情况下使用高复制系数对性能是一种伤害。

图 6
图 6 是在多个服务器上增加线程数时的吞吐量变化情况。Anna 的复制系数设置为 3，先是启动第一台服务器的 32 个线程，然后是第二台服务器的 32 个线程，最后是第三台服务器的所有剩余线程。从图中可以看出，Anna 的吞吐量随着线程数量的增加呈线性增长。在启动第 33 个线程时吞吐量有轻微下降，不过那是因为第 33 个线程是属于第二台服务器的。但从整体来看，吞吐量的增长是很稳定的。可见，借助 Anna 的无协调 actor 模型，是可以实现吞吐量线性增长的。

与其他系统的比较
为对比 Anna 与其他流行键值系统之间的性能差异，RISE 研究员设计了两次实验，第一次在单节点上与 Redis 进行对比，第二次在一个大型的分布式系统上与 Cassandra 进行对比。

Anna 具有多线程并行能力，而 Redis 使用的是单线程模型。所以，在第一次实验中，他们在同一台服务器上搭建了一个 Redis 集群，让 Anna 与这个集群进行比较。实验是在 AWS 的的 EC2 实例上运行的，其中 Redis 集群使用了尽可能多的线程。

图 7
从图 7(a) 可以看出，在高并发情况下，Redis 集群的整体吞吐量几乎保持不变，而 Anna 可以在副本之间分散热键。Anna 的吞吐量随着复制系数的增加而增长，直到达到平缓。如果热键完全被复制，吞吐量还会随着线程的增加继续增长。从图 7(b) 可以看出，在低并发情况下，Anna 和 Redis 集群都获得了不错的并行能力，它们的吞吐量都随着线程数的增加而增长。

从这次实验可以看出，在高并发情况下，Anna 通过复制热键的方式在性能方面吊打 Redis 集群，而在低并发情况下，Anna 可以与 Redis 集群达到相似的性能。

在第二次实验中，RISE 研究员将 Cassandra 的一致性设置为较低级别（ONE），也就是说，只要一个节点确认就表示更新操作成功。他们在 AWS 的四个 EC2 可用区域（奥尔良、北弗吉尼亚、爱尔兰和东京）上运行该实验，并通过调整可用区域的节点数量来评测它们的伸缩性。它们的复制系数都被设置为 3。

图 8
从图 8 可以看出，随着节点的增加，Anna 和 Cassandra 的性能都呈现出线性增长。不过，Anna 比 Cassandra 的性能高出一大截。事实上，在每个节点使用 4 个线程时，Anna 就可以打败 Cassandra，而当把所有的线程都用上，Anna 比 Cassandra 的性能高出 10 倍以上。

参考资料：
https://rise.cs.berkeley.edu/blog/anna-kvs/?twitter=@bigdata
论文原文：
http://db.cs.berkeley.edu/jmh/papers/anna\_ieee18.pdf
源代码：
https://github.com/cw75/fluent
\section{迁移数据库}
目前AutoPDMS使用ACCESS数据库系统，将不能满足互联网应用需求，更不能满足云系统和物联网系统需求。因此需要迁移数据库系统：

第一步是迁移到MySQL或MariaDB系统，第二步是迁移到REDIS或其它NoSQL系统。
\subsection{迁移ACCESS数据库到MySQL数据库}
\subsubsection{用例：一次性迁移一个AutoPDMS项目}
点击UPGradeDB项目界面中上部按钮升级，一次性迁移一个AutoPDMS项目ACCESS格式数据库到MySQL格式数据库。
\subsubsection{用例：一次性迁移所有AutoPDMS项目}
点击UPGradeDB项目界面中上部按钮升级，一次性迁移所有AutoPDMS项目ACCESS格式数据库到MySQL格式数据库。
\subsubsection{用例：用户登录时一次性迁移该AutoPDMS项目}
用户登录时，一次性迁移该AutoPDMS项目ACCESS格式数据库到MySQL格式数据库。用户可以选择是否迁移。
\section{云设计}
迁移AutoPDMS项目ACCESS格式数据库到MySQL格式数据库以后，把MySQL格式数据库存储在阿里云或腾讯云服务器。用户可以选择是否登录云服务器进行云设计。
\subsection{用例：局域网内单机设计}
目前AutoPDMS软件已经广泛应用在这种场景。
\subsection{用例：局域网共享协同设计}
目前AutoPDMS软件不少用户应用在这种场景。它基于Windows系统共享文件协议共享ACCESS数据库文件实现。
\subsection{用例：局域网协同设计\label{localnetcodesign}}
目前AutoPDMS软件没有这种功能。它基于ODBC协议访问MySQL数据库实现。
\subsection{用例：互联网协同设计\label{internetclouddesign}}
目前AutoPDMS软件没有这种功能。它基于ODBC协议访问远程MySQL数据库实现。

这种场景实现了真正的云设计。如何保证云设计的网络访问速度？能否在遇到网络流量瓶颈或断网时转换为本地设计，即实现github那样的分布式网络云设计？
\subsection{用例：分布式云设计\label{distributionclouddesign}}
目前AutoPDMS软件没有这种功能。有多种实现方案。
\subsubsection{用例：基于gitlab分布式云设计\label{Gitdistributionclouddesign}}
目前AutoPDMS软件没有这种功能。它结合\ref{localnetcodesign}和\ref{internetclouddesign}两者功能，基于ODBC协议访问MySQL数据库和gitlab协议、git协议实现。
\section{登录方式}
登录对话框下部有QQ、微信、Facebook图标，点击它们可以登录云设计系统。
\subsection{用例：AutoPDMS传统登录方式}
\subsection{用例：微信登录方式}
\subsection{用例：QQ登录方式}
\subsection{用例：淘宝网登录方式}
\subsection{用例：Facebook登录方式}

\section{即时通信}
登录进入云设计系统后，可以使用即时通信和云平台的设计人员以及优易软件公司用户群的用户或技术支持人员沟通。

\section{分享屏幕}
登录进入云设计系统后，可以建立团队协作群，召开视频会议，讨论方案，或与某个人沟通寻求技术支持。点击屏幕分享，加入该会议的人可以看到屏幕，类似QQ视频会议分享屏幕功能。

\section{审核方案}
登录进入云设计系统后，可以建立团队协作群，讨论和审核方案。点击审核方案，加入该会议的人可以看到自己计算机的AutoPDMS模型或节点随着操作者的点击改变。

要比较本功能与分享屏幕功能速度，选择反应速度快的方案。

\section{培训用户}
登录进入云设计系统后，可以建立团队协作群，培训用户。点击培训用户，加入该会议的人可以看到自己计算机的AutoPDMS模型或节点随着教师的点击改变。

\section{升级软件}
登录进入云设计系统后，系统检查是否有新发布版本。如果有，提示用户选择是否升级。如果用户选择是，则软件开始下载，完成下载后自动安装并重新启动软件。

\part{功能设计}
\section{迁移数据库}
迁移数据库有多种实现方案。基本方案是利用ADO访问ODBC驱动程序，把ACCESS数据库迁移到MySQL或MariaDB、PostgreSQL数据库。
\subsection{ODBC}
1991年11月，微软宣布了开放数据库连接ODBC，次年推出可用版本。

1992年2月，推出了ODBC SDK 2.0版。ODBC基于SAG的SQL CAE草案所规定的语法，共分为Core、Level 1、 Level 2三种定义，分别规范了22、16、13共51条命令，其中29条命令甚至超越了SAG CLI中原有的定义，功能强大而灵活。它还包括标准的错误代码集、标准的连接和登录DBMS方法、标准的数据类型表示等。

由于ODBC设计架构和实现的先进性，且没有同类的标准或产品与之竞争，它一枝独秀，推出后仅仅两三年就受到了众多厂家与用户的青睐，成为一种广为接受的标准。目前，已经有130多家独立厂商宣布了对ODBC的支持，常见的DBMS都提供了ODBC的驱动接口，这些厂商包括Oracle、Sybase、Informix、Ingres、IBM(DB/2)、DEC(RDB)、HP(ALLBASE/SQL)、Gupta、Borland(Paradox)等。目前，ODBC已经成为客户机/服务器系统中的一个重要支持技术。
\subsection{开源iODBC}
iODBC是一个开源的ODBC驱动程序管理器和SDK，可以在linux，freebsd，unix和MacOS X平台上开发独立于数据库的应用程序，代码在 https://github.com/openlink/iODBC/
\subsection{使用AutoPDMS域对象连接MySQL}
AutoPDMS已经模仿MSADO封装了一个UEADO，实现了持久层域对象，并连接了持久层域对象和AutoPDMS域对象。现在UEADO已经支持ACCESS，只需要增加支持MySQL或MariaDB或PostgreSQL或REDIS即可连接MySQL。
具体要增加的接口如下：
\subsubsection{SQLGetInstalledDrivers ODBC驱动程序列表}
使用SQLGetInstalledDrivers函数获取已经安装的ODBC驱动程序列表，根据返回的szDrivers字符串是否含有MySQL字符识别是否为MySQL ODBC驱动程序。

\#include "stdafx.h"

\#include <Windows.h>

\#include <ODBCINST.H> 

void GetSQLDriverList()\{	TCHAR szDrivers[4096];	memset(szDrivers, 0, sizeof(szDrivers));	

WORD wRet = 0;	

if(SQLGetInstalledDrivers(szDrivers, sizeof(szDrivers), \&wRet))	

\{		wprintf(\_T("Installed driver list:\textbackslash n"));		

LPTSTR pszDrv = szDrivers;		

while(*pszDrv)		

\{			wprintf(\_T("\%s\textbackslash n"), pszDrv); 			

pszDrv += \_tcslen(pszDrv) + 1;		

\}		wprintf(\_T("\textbackslash n"));      	

\}\} 
--------------------- 
作者：hellokandy 
来源：CSDN 
原文：https://blog.csdn.net/hellokandy/article/details/80884692 
版权声明：本文为博主原创文章，转载请附上博文链接！

\subsubsection{ODBC注册DSN}
BOOL SQLConfigDataSource(HWND hwndParent, UINT
fRequest,LPCSTR IpszDriver, LPCSTR IpszAttributes);

无论是用ODBC还是DAO、ADO类，在访问ODBC数据源以前，都必须先注册DSN。通过调用函数SQLConfigDataSource，可以实现自动注册DSN。详见 \cite{auragreen}。
\subsubsection{重构函数UPGrade}
重构函数CUpdatedbOprate::UPGrade(CString strSourcePath, CString strAimPath)以及调用的相关函数，使其支持源数据库和目标数据库连接可以使用不同的驱动程序连接。该函数代码在
h:\textbackslash vc\textbackslash AutoPDMS9.0\textbackslash 升级\textbackslash APUPGradeDB\textbackslash Src\textbackslash UpdatedbOprate.cpp
\subsection{迁移ACCESS数据库到MySQL数据库}
\subsubsection{功能设计：一次性迁移一个AutoPDMS项目}

\subsubsection{功能设计：一次性迁移所有AutoPDMS项目}

\subsubsection{功能设计：用户登录时一次性迁移该AutoPDMS项目}

\section{云设计}
迁移AutoPDMS项目ACCESS格式数据库到MySQL格式数据库以后，把MySQL格式数据库存储在阿里云或腾讯云服务器。用户可以选择是否登录云服务器进行云设计。
\subsection{功能设计：局域网内单机设计}
目前AutoPDMS软件已经广泛应用在这种场景。
\subsection{功能设计：局域网共享协同设计}
目前AutoPDMS软件不少用户应用在这种场景。它基于Windows系统共享文件协议共享ACCESS数据库文件实现。
\subsection{功能设计：局域网TCP/UDP协同设计\label{localnetcodesign}}
目前AutoPDMS软件没有这种功能。它基于ODBC协议访问MySQL数据库实现。这是我猜的，可能功能设计并非如此。
\subsection{功能设计：互联网协同设计\label{internetclouddesign}}
目前AutoPDMS软件没有这种功能。它基于ODBC协议访问远程MySQL数据库实现。

这种场景实现了真正的云设计。如何保证云设计的网络访问速度？能否在遇到网络瓶颈时转换为本地设计，即实现github那样的分布式网络云设计？
\subsection{功能设计：分布式云设计\label{distributionclouddesign}}
目前AutoPDMS软件没有这种功能。有多种实现方案。
\subsubsection{功能设计：基于gitlab分布式云设计\label{Gitdistributionclouddesign}}
目前AutoPDMS软件没有这种功能。它结合\ref{localnetcodesign}和\ref{internetclouddesign}两者功能，基于ODBC协议访问MySQL数据库和gitlab协议、git协议实现。	
	\section{其他的需求}
	\section{有待解决的问题列表}
	\section{附录}
	无。
	
	\section{云系统功能评估表}
	
	
	\begin{thebibliography}{99}

	\bibitem{newton} Newton, I., and Motte, A. (translated), \textit{MATHEMATICAL PRINCIPLES OF NATURAL PHILOSOPHY AND HIS SYSTEM OF THE WORLD}.,University of California Press Berkley and Los Angeles, California,(1974).

\bibitem{wangkedi} 牛顿, 伊萨克原著. and 王, 克迪.译, \textit{自然哲学之数学原理}.,陕西人民出版社.武汉出版社, 中国,(2001).

\bibitem{chenshouzhu} 程, 守洙. and 江, 之永, \textit{普通物理学}.第4版,人民教育出版社, 中国,(1982).

\bibitem{feihejin} 菲赫金哥尔茨, 格.马. 原著 and 丁, 寿田译, \textit{数学分析原理第二卷第二分册}.第1版,人民教育出版社, 中国,(1962).
()+第一卷
\bibitem{bineteq} Binet, J.P.M. ,  \textit{Binet equation}.,https://en.wikipedia.org/wiki/Binet\_equation (2018).

\bibitem{Zienkiewicz} Zienkiewicz, O.C. and Taylor, R.L., \textit{The finite element method}.McGraw-Hill Book Company (1989).

\bibitem{Zienkiewicz2} Zienkiewicz, O.C., Taylor, R.L. and Nithiarasu, P.,
\textit{The finite element method for fluid dynamics}. 6th edition, Elsevier (2006).

\bibitem{Hughes} Hughes, T.J.R., \textit{The Finite Element Method}. Dover Publications Inc.Mineola, New York (2000).

\bibitem{Dhondt} Dhondt, G., \textit{The Finite Element Method for 		Three-Dimensional Thermomechanical Applications}. John Wiley \& Sons, (2004).

\bibitem{Pacher} Pacher, M., 
\textit{}.  Master Thesis, University of Trento, Italy (2016).

\bibitem{Chapman} Chapman, S., Cowling,T.G.,
\textit{The Mathematical Therory of Non-Uniform Gases}.  3rd ed., Cambridge University Press, England (1970).

\bibitem{BENZI1992145}Benzi,R., Succi,S., and Vergassola,M.,\textit{The lattice boltzmann equation: theory and applications.} ,Physics Reports, 222(3):145 -- 197, 1992.	

\bibitem{guozhaoli} 郭, 照立 and 郑,楚光,
\textit{格子Boltzmann方法的原理及应用}. , 科学出版社, 中国 (2009).

\bibitem{fbaotian} Xu,Lincheng,Tian, Fangbao, 
\textit{ A novel geometry-adaptive Cartesian grid based immersed boundary–lattice
	Boltzmann method for fluid–structure interactions at moderate and high
	Reynolds numbers}. University of New South Wales, Australia (2018).

\bibitem{ccxmanual} 李, 国斌等译, and Dhondt, G.,\textit{CalculiX CrunchiX 用户手册 版本2.14}. ,中国, (2018).

\bibitem{mordernos} 陈, 向群等译, Tanenbaum, \textit{现代操作系统}. ,机械工业出版社 , (2009).

\bibitem{yangkzh} 杨, 开振, \textit{深入浅出MyBatis技术原理与实战}., 电子工业出版社 , (2016).

\bibitem{chnpdms115} 王元,\textit{AVEVA PDMS基础 }. \htmlref {/ / Systemuk/ d/ PDMS中文教程11.5}. ,AVEVA中国, (2004).	

\bibitem{chnpdms} 张伟群,\textit{AVEVA PDMS培训手册 }. \htmlref {/ / Systemuk/ d/ PDMS中文教程新版}. ,AVEVA中国, (2003).

\bibitem{apdevdoc} uesoft,uksoft,  \textit{AutoPDMS9.0开发文档}. \htmlref {/ / Systemuk/ e/ VC/ AutoPDMS9.0-Document/ 开发文档}., UESOFT, 湖南,长沙,(2017).

\bibitem{apdoc} uesoft,uksoft,  \textit{AutoPDMS10.4帮助文档}. \htmlref {H:/ Program Files (x86)/ 长沙优易软件开发有限公司/ AutoPDMS10.4.4/ Help/ AutoPDMS10.4帮助文档.doc}.,UESOFT, 湖南,长沙,(2018).

\bibitem{psadoc} uesoft,udsoft,  \textit{AutoPSA用户指南}. \htmlref {H:/ Program Files (x86)/ 长沙优易软件开发有限公司/ AutoPSA9.3/ Help/ AutoPSA用户指南.doc}., UESOFT, 湖南,长沙,(2018).
		
		\bibitem{zhuyiwencyq} 朱,以文, and 蔡,元奇等. (译), \textit{abaqus从入门到精通}.,武汉大学建筑学院, 湖北,(2003).
		\bibitem{ligb} 李,国斌, and 等. (译), \textit{PDMS PROPCON 属性库参考手册11.6版中文版}.,长沙优易软件开发有限公司, 湖南,(2018).
		\bibitem{ligbpsa} 李,国斌, and 等. (译), \textit{AutoPSA技术参考手册}.,长沙优易软件开发有限公司, 湖南,(2016).
		\bibitem{caesarii} coade, and 等. , \textit{CAESARII Technical Reference Manual}.,Coade Inc., Texas,(2006).
		\bibitem{auragreen} auragreen,\textit{ODBC注册DSN},https://blog.csdn.net/auragreen/article/details/46620073, csdn,(2015).
		
		
	\end{thebibliography}
	
	%\end{multicols}
	
	
\end{document}